A domain may be a single organization, a closed user group, a company, or a community with logical (administration, policy, or management) and/or physical (network or security device) separation from the rest of the world. A single domain may include multiple zones with logical and/or physical demarcations. Examples of a single domain can include, without limitation, an enterprise with some LAN endpoints, some Internet-connected endpoints and some mobile endpoints, or an enterprise with endpoints within a single network that use different technology or protocols. Examples of different technology or protocols may include different types of signaling, such as SIP (Session Initiation Protocol), H.323, WebRTC (Web Real Time Communication), and TIP (Telepresence Interoperability Protocol), and different types of media codecs, such as H.264, H.265 and VP8.
When a communications session that includes video or telepresence is desired across multiple domains, or across zones within a domain, a series of problems arise that often prevent the communications session from being successfully executed, or attempted. These problems create a perception that the communications session will not work or will be too hard or costly, a perception that is often correct, and even when not, prevents the session from being attempted.
The problems that arise can be grouped into the following categories: 1) technology and capability; 2) connectivity and routing; 3) session authentication and initiation; 4) resources; and security and policy implementations. Technology and capability problems may include domains that use video and communications systems, which are not directly compatible with one another due to heterogeneous technologies, protocols and/or configurations. Certain capabilities, services, applications or data may not be available within each domain, or the domains may differ in these capabilities or in the implementation of these capabilities, e.g. data sharing protocols, encryption, collaboration tools, recording or presence. Consequently, in such a prior art system, the communications session may not work, or may not efficiently use those capabilities.
Connectivity and routing problems may include the absence of physical network connectivity layer two through layer five routing between the domains. In addition, connectivity and routing may not extend to cover all zones within the domains, for example, zones of mobile or Internet video endpoints.
Session authentication and initiation problems may include domains that do not have the capability to schedule, authenticate, initiate and/or launch the desired communication session because they may not have inter-domain directory, scheduling, authentication, initiation and/or launch services. Further, the domains may not have universal standards, methods and/or connectivity to leverage. For example, a video endpoint does not have a native capability to call any other video endpoint unlike a public switched telephone network (PSTN) where any PSTN telephone can call any other telephone. Session authentication and initiation is also an issue in applications that wish to incorporate video, e.g. web conferencing, workflow applications and customer call center type applications. In these types of applications, there are no standardized ways to incorporate standard video clients and endpoints.
Resource problems may include inadequate bandwidth, computing, bridging, MCU and/or like resources for video sessions, as prior art systems do not optimize the use of such resources between different domains and many of these resources are scarce, expensive and/or shared.
Security and policy implementation problems may include one or more domains that have extremely broad policy or security rules or implementations that may prohibit the sessions because prior art systems make inter-domain security policies impossible to implement and manage at a more granular and effective level.
Due to these and other limitations of prior art systems, inter-domain communications sessions that include video or telepresence, usually fail for one of a few reasons: 1) users assume that their inter-domain communications session cannot include video or telepresence endpoints outside of their domains so they do not attempt it; 2) users want to attempt an inter-domain communications session but do not know how to initiate and launch the session, e.g., how to call the other parties, and/or how to secure a bridge for multiple other parties; and 3) users attempt an inter-domain communications session but the capabilities are too low, the costs too high, and/or the user experience is too cumbersome and time consuming. Consequently, communications sessions that include inter-domain video are typically a very small percentage of today's enterprise video sessions. Similar problems are found inside large domains with multiple zones.
Accordingly, a need exists for improved technology and methods for executing and managing inter-domain communications sessions that include video or telepresence, which make it feasible for such sessions to be attempted, and to make attempted sessions successful. A similar need exists inside domains, particularly among domains that contain multiple zones.